MacOS X Developer Preview 4 Release Notes Copyright © 2000 by Apple Computer, Inc. All Rights Reserved.
The Foundation Framework is a library of Objective-C classes that provide the infrastructure for object-based applications without graphical user interfaces as well as for most other Cocoa frameworks, most notably the Application Kit. Foundation consists of basic classes used by any Objective-C program:
The Objective C runtime is no longer embedded within the Foundation framework. The runtime is now contained in the library /usr/lib/libobjc.dylib. However, you should continue to link with the Foundation framework rather than the runtime, if possible. A number of APIs which have alternatives within the CoreFoundation or Cocoa frameworks have also been obsolesced and even removed.
The obsolete NXBundle, NXStringTable, Storage, and StreamTable classes, along with their headers, have been removed. The function objc_getModules() has also been removed from the runtime.
The command line utility objcunique, which used to help in prebinding binaries, no longer does anything interesting.
These APIs have been obsolesced. These APIs should not be used for new programs, and use of these APIs should be converted to alternatives as soon as possible.
All APIs which took or returned NXZone * parameters have been changed to take or return void * parameters; for return values, malloc_zone_t * are now returned (which can be used interchangeably with NXZone * currently); NXZone * parameters will continue to be accepted for now, but when the NXZone API is obsolesced so will that; these functions also accept malloc_zone_t * parameters. The List and HashTable classes now ignore all zone parameters.
Projects using Objective C are cautioned to identify uses of Objective C runtime APIs, and eliminate them if possible, in the event some are obsoleted after Mac OS X ships its first release. If you can localize your dependencies, you will be impacted less by possible future new versions of the runtime.
This includes all APIs in all objc/*.h headers, except for these types and constants in objc/objc.h: Class, id, SEL, IMP, BOOL, YES, NO, Nil, nil
You should also NOT:
Use of the @selector() Objective C language expression is a tricky issue with respect to possible future language directions, since in coding an @selector() expression, a programmer is effectively coding in some knowledge of how a method declaration is mangled into a selector. This should be the purview of the compiler and the runtime alone. However, there is no alternative currently, so we must live with this for now.
Finally, you should reconsider uses of the Objective C language @defs() expression on classes which are not your own.
Do NOT traverse the method lists in an Objective C class yourself; use the class_nextMethodList() function if you have to do this at all.
Do not use Objective C from within a library initialization routine if you can avoid it. The Objective C runtime is not initialized at the time library initializers are executed.
In order to avoid naming collisions, NSUserDefaults now stores an application's defaults under a file named from the main bundle's identifier; if the bundle's identifier has not been set, the defaults are stored under the application's name, as always. For the most part, this change should be transparent to users, except that defaults will have been lost the first time the app is run under the new naming scheme. For more on the bundle identifier, see /System/Documentation/Developer/ReleaseNotes/InfoPlist.html.
The defaults command (/usr/bin/defaults) has changed extensively in order to support the new options available for defaults. The old syntax continues to work as expected, but there are several new options available. Execute "defaults help" to get a full listing of the new options and syntax.
Some API in the NSDebug.h header has been removed and obsolesced:
There is a known severe bug in NSUndoManager which causes undo to be unreliable at best. It may also cause some unusual side-effects, possibly including raises, when an undo group is closed. We expect the bug to be fixed in the next release of MacOS X.
The methods -searchList and -setSearchList: are now fully obsoleted; calling them will do nothing. Instead, we have added the methods -addSuiteNamed: and -removeSuiteNamed:. These add or remove the domains pertaining to the named suite, and are intended for use by framework and suite developers that wish to set and retrieve preferences which pertain to potentially several applications, but which do not wish to use NSGlobalDomain for the purpose. Once a named suite has been added, its defaults are placed in NSUserDefaults' search list, and will be found in the normal fashion. Suite defaults can be written by calling -setPersistentDomain:forName:, passing the suite's name as the domain name.
There is a new class, NSMachPort, which is a concrete subclass of the abstract NSPort class. NSMachPort is an object wrapper for a Mach port, and is only available on Mach.
There are two other new NSPort concrete subclasses, NSMessagePort and NSSocketPort, which can be used as endpoints for DO connections (or raw messaging). A subclass of NSPort represents a particular flavor of data transport from one process to another. Note that instances of port subclasses cannot be mixed on a particular communication channel. For example, a client cannot connect to a server using NSMessagePort if the server only supports connections made with NSSocketPort. Also, you cannot transfer instances of NSMessagePort in a message to another process over a channel which is using NSSocketPorts as its endpoints; you can only pass NSSocketPorts on such a channel. These restrictions apply to any subclasses of NSPort, not just NSMessagePort and NSSocketPort. However, you are free to create other connections to a server using other subclasses of NSPort (assuming the server supports multiple transports) and send instances of that other subclass on that channel.
NSMessagePort allows for local (on the same machine) communication only. NSSocketPort allows for both local and remote communication, but may be more expensive than NSMessagePort for the local case; there is also no name registry service for NSSocketPorts -- clients and servers must agree on the TCP port numbers to use beforehand.
The following NSPort methods are obsolete. If you want to create an NSPort wrapping a Mach port, use the new NSMachPort class.
The following NSPortMessage method is obsolete. Implement the -handlePortMessage: delegate method instead of -handleMachMessage: (which now only applies to NSMachPort instances) if you want messages sent in the default internal packaging format unpacked.
Subclasses of NSPort must now implement these two new methods to setup monitoring of the port when added to a run loop, and stop monitoring if needed when removed.
There is a new concrete subclass, NSMessagePortNameServer, of the NSPortNameServer class. NSMessagePortNameServer takes and returns instances of the NSMessagePort class.
NSUserDefaults now supports saving and retrieving NSNumber and NSDates, as well as the other traditional classes. One side-effect of this which may be unexpected is that -objectForKey: may now return objects of the new classes. This may cause older code that makes assumptions about the class of the returned object to fail, or even crash. We recommend that clients verify that their code correctly checks the class of the returned object before messaging, as any of the various property list classes may be returned.
In addition, the following two methods in the NSUserDefaults class are being obsolesced:
This is in preparation for exporting the full feature set of CFPreferences through NSUserDefaults. Calling these methods now generates a console log. For now, the methods still function as well as they can, but their behavior is not guaranteed, and clients should move off them as soon as possible.
Foundation now links with the new CoreFoundation framework, and several classes in Foundation are now implemented in terms of the new APIs in CoreFoundation. Some classes are also "toll-free bridged" with their CoreFoundation counterparts. What this means is that the CoreFoundation type is interchangeable in function or method calls with the bridged Foundation object. For example, CFArray and NSArray are toll-free bridged, which means than in API where you see an NSArray * parameter, you can pass in a CFArrayRef, and in API where you see a CFArrayRef parameter, you can pass in an NSArray instance. This applies to all libraries, not just CoreFoundation and Foundation. It also applies to developers' concrete subclasses of abstract types like NSArray.
However, not all Foundation classes have counterparts in CoreFoundation, and even of those which seem to have counterparts, not all are (or will ever be) toll-free bridged. For example, there is a CFRunLoop type and an NSRunLoop class. These are not toll-free bridged, however, and are not interchangeable. NSRunLoop does however use CFRunLoop in its implementation.
Here is a list of types and classes which are toll-free bridged in this release. More may be bridged in the future.
The Mach Name Server is not present in Mac OS X. Distributed Objects relied on the Name Server to provide cross-host transport for Mach messaging (and Mach ports) and a string-name-to-port mapping service. The result is that there is no cross-host transport for Distributed Objects provided in Mac OS X Developer Preview 1, though Apple is considering adding a built-in cross-host transport facility in Foundation in the future.
In possible anticipation of a new transport facility and to assist developers writing their own D.O. transports or naming services, Distributed Objects has been modified somewhat in this release. The new class and list of new and obsolete methods can be seen in the following sections.
There is a new class NSMachBootstrapServer, a subclass of NSPortNameServer, which provides access to the Mach Bootstrap Server. This class is only available on Mac OS X. Note that the Bootstrap Server does not support port checkout capability (the port must be destroyed to remove a checked-in entry), and the inherited removePortForName: method does nothing.
In Mac OS X, NSMachBootstrapServer is the default port name server for D.O. The default used to be a private class which used the Mach Name Server.
These methods allow a port name server instance to be specified for the operation. The old methods of similar name, without the usingNameServer: parameter, continue to use the default port name server, returned by the systemDefaultPortNameServer method, below.
This method returns the hard-wired default port name server for Distributed Objects. In Mac OS X, this is an instance of NSMachBootstrapServer.
This is simply the init method for the pre-existing class creation method which autoreleases its return value.
The method which an NSPortMessage uses to send itself on a port. There is a method of similar name, which does not allow the msgh_id of a Mach message to be specified. If you were overriding that abstract method on NSPort, you should now override this one as well. The msgid parameter may not be used by some NSPort subclasses.